Project Detroit

JavaScriptからJavaクラスを呼び出せる仕組み

大きく 3層のブリッジ構造 になっています。

サンプルコードを見ると、JavaScript 側では次のような書き方ができます。

code:javascript

// Javaの型をJSの変数として取得する

var Runnable = Java.type("java.lang.Runnable");

var Thread = Java.type("java.lang.Thread");

// JavaScriptのオブジェクト記法でJavaインターフェースを実装する

var r = new Runnable({

run: function() {

print("I am a runnable " + Thread.currentThread());

}

});

r.run();

code:javascript

// JavaImporter でパッケージ単位にインポートすることもできる

with (new JavaImporter(java.io, java.net, java.lang.StringBuilder)) {

var buf = new StringBuilder();

// ... java.io や java.net のクラスが使い放題

}

code:javascript

// java.lang.System などはドット記法でそのままアクセス可能

var console = java.lang.System.console();

3層目：リフレクション + コード生成でクラスをラップ

2. そのクラスに対応する V8のオブジェクトテンプレート（JavaScript オブジェクトの「型」に相当するもの）を C++ レベルで生成する

つまり「Javaクラスの情報をリフレクションで読み取り、V8のオブジェクトとして見えるようにラップする」というアプローチです。

逆方向：JavaScriptで実装したインターフェースをJavaに渡す

まとめ：データの流れ

code:_

JavaScript (V8)

↕ V8 Object Template / Callback

C++ ブリッジ層 (jvmv8_*.cpp)

↕ JNI (Java Native Interface)

Java (JVM)

↕ Reflection / Dynamic Proxy

Javaクラス・インターフェース

要するに、C++ が JVM と V8 の両方に対して「通訳」として機能し、リフレクションとコード生成によってJavaの型体系をそのままJavaScript側に透過的に見せる、という設計です。GraalVM の Polyglot API に近い発想ですが、こちらは純粋に V8 ベースで実現しているのが特徴です。

JNIの警告問題と対応

警告が出るようになった経緯

具体的には、以下のいずれかを行うと警告が発生します。

detroit-js の対応

code:bash

java \

--module-path $lib \

--add-modules org.openjdk.engine.javascript \

--enable-native-access=org.openjdk.engine.javascript \ ← ここ

org.openjdk.engine.javascript.Main "$@"

まとめ

Panamaは使われていない

代わりに採用している方式は正統派JNIで、コードを見ると：

という古典的なJNIアプローチです。

なぜPanamaではなくJNIを選んだか（推測）

V8との連携にFFM APIを使わない理由はいくつか考えられます。

FFM APIのトレードオフとして、FFM APIはCとのやりとりには強い一方、複雑なC++オブジェクトとの相互運用（V8のような高機能なC++ライブラリ）には向いていません。V8のAPIはC++のクラス・テンプレート・コールバックを多用するため、FFMよりJNIのほうが自然なマッピングになります。